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TITLE: Multi-modal traveler information system 

Primary Examiner (1) : 
Corrielus ; Jean M. 

Brief Summary Text (8) : 

Previous implementations of similar concepts have focused on decomposing the 
transportation grid into preselected roadway segments that travelers can access via 
predetermined codes. While this approach may be an improvement over general 
broadcast methods, it does not address multi -modal travel (e.g. using different 
forms of transportation) , may cause the end user a significant amount of 
involvement in obtaining the information and does not support the concept of 
limiting notification to only times when travel conditions affect the user. 
Further, previous implementations of similar concepts have not been fully 
generalized to communication systems by which the user may wish to receive 
information. 

Brief Summary Text (10) : 

Accordingly, it is seen that prior approaches to limitation of travel information 
provided to a user have been insufficiently specific to the user's needs and 
insufficiently flexible in regard to communication media which may be employed or 
the route and possible modes of travel which may be of interest to the user and do 
not support full flexibility of choice in travel routes, conveyance and other 
choices which may be made by a traveller in the process of expeditiously reaching a 
destination. 

Brief Summary Text (12) : 

It is therefore an object of the present invention to provide a system and method 
for matching travel condition information to a user's needs and preferred 
communication media and utilization thereof, such as automatic notification or 
call-in/information on demand. 

Drawing Description Text (11) : 

FIG. 9A and 9B together form a flow chart for determining customers that need to be 
automatically notified in accordance with the invention, 

Drawing Description Text (16) : 

FIG. 14 is a flow chart illustrating a preferred operation in accordance with the 
invention for managing automatic subscriber notification, 

Drawing Description Text (17) : 

FIGS. 15A and 15B are flow charts illustrating a preferred operation in accordance 
with the invention for conducting automatic subscriber notification, 

Detailed Description Text (4) : 

Specifically, as shown in FIG. 1, the multi-modal travel information system 100 in 
accordance with the invention .receives real-time travel condition information from 
an information infrastructure 2 0 and preferably includes, for example, information 
concerning accidents, construction, special events (planned or unplanned) and 
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weather information. The information, as received, may or may not be correlated 
with travel modes 30 and some degree of correlation, such as railroad or tramway 
conditions which are generally unique to those travel modes, or weather conditions 
which affect all modes of travel except subways, may be inherent in the data. 

Detailed Description Text (5) : 

The Multi -Modal Traveler Information System (MTIS) 100 significantly reduces the 
traveler's burden and frustration with the additional and often irrelevant 
information reported by known systems through dissemination of portions of the 
generalized travel conditions information 20 based upon their personalized multi- 
modal profile input thereto, as depicted at 40. This personalized multi -modal 
profile would contain such items as the traveler's name, preferred travel mode(s) 
(e.g. roadway, bus, subway, rail, ferry, air, tramway, etc.), primary and alternate 
travel route (s), travel time(s), notification time window(s) during which travel is 
anticipated, and preferred information delivery device (s) (e.g. telephone (wired & 
wireless), pager (one-way & two-way), e-mail, facsimile, Internet, Intranet, in- 
vehicle device, etc.), collectively depicted at 60. It is with this personal 
information 40 that the system 100 is able to construct a filter that provides the 
end user with personalized travel conditions information. 

Detailed Description Text (6) : 

Dissemination of personalized information is provided by means of any end user 
device that is compatible with transmission of real-time voice, video or digital 
message information (e.g. telephone (wired & wireless), pager (one-way & two-way), 
e-mail, facsimile, Internet, Intranet, in-vehicle device, etc.). For devices that 
support two way communications, such as the telephone, Internet and two way pagers, 
end users may request personalized information at any time. For all devices, the 
end user may have the system notify them automatically according to a set of 
notification criteria such as time of day, information thresholds, (e.g. depth of 
snow, total length of anticipated delays, total travel time, required arrival time, 
etc. ) , and the like. 

Detailed Description Text (8) : 

The preferred implementation of this invention for dissemination of personalized 
travel conditions information (accidents, congestion, delays, travel times, 
construction, weather, special events and road surface conditions) to travelers 
uses any combination of travel modes (e.g. roadway, bus, subway, rail, ferry, air, 
tramway, and the like). Travel conditions information specific to a traveler's 
multi -modal travel routes would be immediately available to those who have 
registered their multi -modal travel routes and notification criteria 4 0 with a 
service provider. Preferably, information content, communications protocols, and 
information geographic referencing would all be in accordance with existing 
industry standards and evolving Intelligent Transportation Systems (ITS) open 
systems standards. Source providers of general travel conditions information 20 
would include traffic operations centers, traveler information centers, or any 
other information service provider (e.g. news wire service) who provides the real- 
time travel conditions information in industry and open systems standard formats. 
Again, the invention does not rely on any particular communication protocols or 
non-public geographic referencing methods. 

Detailed Description Text (9) : 

As will be discussed in greater detail below, new customers register with a service 
provider (via communication with a customer service representative or the personal 
Internet interface, generally indicated at 40 of FIG. 1).. Data elements are- 
collected/captured for their personal profile for uniquely identifying the 
traveler, their personal travel route (s) and their preferred notification criteria 
and communication device (s) for information delivery. Each route defined within the 
profile contains a description, origin, multi-modal path and destination. Customers 
may register particular route (s) for automatic notification . The notification 
criteria includes the preferred delivery device (e.g., telephone, fax, pager, e- 
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mail, etc.) and the day(s) of week and time(s) of day that travel on the route is 
anticipated. 

Detailed Description Text (10) : 

Generalized travel conditions information is filtered by filters which are built by 
the system 100 according to the information provided in the pre-stored customer 
profiles. The filtering process occurs in multiple stages. In the first stage of 
the filtering process, as will be discussed in detail below, the location of the 
travel condition is compared with the routes in the customer profiles to determine 
which customers may be affected. For those customers that are affected and have 
registered for automatic notification, the filtration process continues with a 
comparison of the customer's notification time window and the expected duration of 
the travel condition. Once the determination has been made that the customer's 
designated notification time window falls some time during the expected duration of 
the event, a determination is then made as to when to notify this customer about' 
the travel condition. The final stage of the filtering process is to determine the 
customer's notification preference (e.g. telephone (wired & wireless), pager (one- 
way & two-way) , e-mail, facsimile, .Internet, Intranet, in-vehicle device, etc.). 

Detailed Description Text (11) : 

The invention provides two modes of operation: user on demand request and automatic 
notification. The user on demand request operation is driven by the end user call- 
in requesting current travel conditions applicable to one of their pre-stored 
routes. Upon receiving the customer's choice of pre-stored route(s), the system 
will determine if there are any current reportable travel conditions that impact 
the selected route. Any reportable travel conditions which impact the selected 
route are then reported to the customer. Automatic notification is driven by the 
occurrence of a travel condition. A travel condition enters the system which 
triggers the event/profile filtering process as described above, and results in a 
customer being notified by means of their preferred notification device. 

Detailed Description Text (33) : 

The function of registering a new customer which develops the data object structure 
depicted in FIG. 5 provides the means for entering the customer's account 
information, their personal travel route (s) and preferred notification criteria. 
The data provided by the customer will be stored in their own customer account in 
the relational database management system (RDBMS) for MTIS 100. FIG. 5 represents 
the structure of the data that is stored in the relational database included by the 
customer service center 2 02 of FIG. 2. 

Detailed Description Text (41) : 

As further depicted in FIG. 5, the customer determines the type of service to be 
provided, either user-on-demand request or automatic notification for each of the 
defined routes 503. Other route specific information that is collected is the 
notification device information and the notification time window defined in an 
object of the customer route detail class 505. 

Detailed Description Text (43) : 

First, MTIS determines if a travel conditions report is for a new travel conditions 
event, an update to an existing event or a closure to a previously reported event 
at 701. If the event is closed, meaning the. travel condition no longer exists, then 
the MTIS deletes customer data associated with that event from the affected 
customers database as illustrated at 703. When there is a new travel conditions 
event or update to an existing event, customers are identified as being affected by 
the reported travel conditions based on their specific areas, route segment 
sequence numbers which defines travel mode, and/or points of interest as indicated 
at 702 and a list of customers to be notified is built at 704. The determination is 
then made as to which customers will need to be automaticall y notified as indicated 
at 706. More specifically, the function of determining affected customers is 
preferably partitioned into three sub-f unctions : Build Affected Customer List 
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(Route Specific) 705, Determine Customers to Auto -Notify 706, and Build Affected 
Customer List (Area Specific) 704. 

Detailed Description Text (45) : 

It should be appreciated that the collective function of 809 and 810 is to 
determine customers which are affected by any event, whether planned or unplanned, 
in order to enable notification which may be ultimately carried out on either a 
call-in or automatic notification basis or both. For a number of reasons, including 
economy, advance knowledge and notification of planned events and the likelihood of 
a customer obtaining knowledge of planned events independently of the system of the 
invention and other expedients discussed below, it is preferred to avoid automatic 
notification of planned events and only include such information with information 
about unplanned events that invoke automatic notification . Thus, as a matter of 
processing economy and system performance, it is preferred to separate planned and 
unplanned events prior to building respective affected customer lists for planned 
and unplanned events. As a design alternative within the scope of the invention, it 
may be preferable to determine if a customer is affected by a planned event at the 
time a customer calls in in order to limit storage of large customer lists. 
Otherwise, processing for determination of customers affected by a planned event 
can be carried out at any convenient time . 

Detailed Description Text (46) : 

Accordingly, further processing of affected customer data occurs is preferably, but 
not necessarily, based on the (planned or unplanned) type of travel conditions 
event determined at 808 as will be discussed in connection with FIGS. 9A and 9B for 
determining which customers to automatically notify . In either case, if there are 
further customers which may be affected by the event, the process then loops to A 
until all customers have been processed to determine if, in fact, their route (s) 
would be affected. 

Detailed Description Text (47) : 

When all affected customers have been determined, the automatic notification filter 
as illustrated in detail in FIGS. 9A and 9B is preferably performed only for those 
travel condition events that are unplanned in nature (e.g. accidents, fires, etc.) 
as indicated by the branch to C from process 810 in FIG. 8. Determining customers 
for Automatic Notification, as illustrated in FIGS. 9A.and 9B is principally based 
on the notification criteria in the customer's profile at 911 and the expected 
duration of the travel condition relative to the customer- specified route 
notification times at 915, 916 and only these processing steps are essential to the 
filtering for automatic notification . 

Detailed Description Text (48) : 

The customer is preferably provided the option to deactivate their MTIS service for 
a specified period of time (e.g. out of town on vacation) and/or the option to 
deactivate the automatic notification service on a particular route. MTIS verifies 
that the customer's profile is currently active at 912 and their pre-stored route 
(s) are also active, as determined at 913, 914 prior to performing the automatic 
notification filtering process 916. Information about the customers that require 
automatic notification are noted as such in the affected customer list which is 
built and stored at 917. It should be appreciated that the testing for active 
customers and routes minimizes the data which must be processed for each unplanned 
event, looping through E. The separation of loops through A, C and E (and F of FIG. 
10, as will be described below) also allows concurrency or pipelining of processing 
of the respective loops to improve system response time. 

Detailed Description Text (49) : 

The sub-function, Build Affected Customer List (Area Specific) 704, determines 
which customers are affected by the reported travel conditions based on the areas 
defined in their customer profile FIG. 10, as illustrated at 1018. It stores 
information about which customers are affected by each reported area travel 
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condition and updates the affected customer list at 1019 when information about an 
area travel condition is updated. In this regard, it should be noted that 
information regarding planned events is made available to automatically notified 
customers upon occurrence of an unplanned event since they will have already been 
placed on a list of affected customers when advance information concerning a 
planned event is received by MTIS 100. The information is also made available to 
automatically notified customers on a call-in basis in advance of the event. In 
this regard, it is preferred in the interest of both desired functionality and 
economy to allow access to personalized travel information on a call-in basis for 
all customers including automatic notification customers as an additional call-in 
function beyond the functions affecting customer account and profile changes, as 
will be discussed below in connection with FIG. 12. Therefore, it is preferred to 
build the affected customer lists 809, 810 at least for unplanned events in 
response to the occurrence or knowledge of the event, even though determination of 
a customer affected by a planned event may not be performed until call-in. 
Automatic notification can also be readily provided by treating a planned event as 
"unplanned" at 808 of FIG. 8 as of the scheduled time of occurrence. If the event 
does not occur as planned, of course, the event may be closed (subject to 
reactivation as an unplanned event at 701, 703 of FIG. 7) . 

Detailed Description Text (51) : 

For automatic notification customers, a determination is made when to notify each 
customer, based on their specified notification time and the current date and time. 
This function also handles the delivery of the travel conditions message (s) to each 
affected customer over their specified device. In the preferred embodiment of the 
invention, the 'Request/Disseminate Personalized Travel Conditions Information 
function has been partitioned into six sub-functions: Disseminate Personalized 
Travel Conditions Information via Phone (User on demand request) , Manage Auto^ 
Notification, Disseminate Personalized Travel Conditions Information via Phone 
(Automatic Notification ) , Disseminate Personalized Travel Conditions Information 
via Phone (Automatic Notification ) , Disseminate Personalized Travel Conditions 
Information via Pager (Automatic Notification ) , Disseminate Personalized Travel 
Conditions Information via Facsimile (Automatic Notification ) , Disseminate 
Personalized Travel Conditions Information via e-mail (Automatic Notification ) . 

Detailed Description Text (56) : 

The functions selectable at 1206 include a number of functions to alter or update 
the customer's personal data profile (which should correspond to the number of 
types of items provided therein) as well as to transfer the call to a customer 
representative for special inquiries and services and to end the call. As will be 
discussed below, travel information can preferably be obtained on a call-in basis 
in the same manner that any other service related to the customer account can be 
selected and the caller' is preferably prompted to select another service after any 
selected service has been completed. 

Detailed Description Text (61) : 

If the customer is affected by route conditions, the customer is prompted to 
specify a previously registered route by a stored voice message which is preferably 
confirmed. Then, as further shown at 1314, a determination is made if the selected 
route is affected. It should be noted that this procedure allows a newly registered 
route to be processed against existing conditions as discussed above in regard to 
FIG. 9B since registration of a new route will cause that portion of the auto^ 
notification list process to become incomplete even if previously completed for all 
previously registered routes. That is, after the process is completed for all 
currently registered routes, it enters a "wait" state depicted by dashed line 919. 
A new route registration then causes branching at 918 to E to process the new route 
and re-entry of the wait state. 

Detailed Description Text (68) : 

Manage Auto -Notification, a preferred form of which is illustrated in detail in 
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